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(54) System for signatureless transmission and reception of data packets between computer 
networks 



(57) A system for automatically encrypting and de- 
crypting data packet sent from a source host to a desti- 
nation host across a public internetwork. A tunnelling 
bridge is positioned at each network, and intercepts all 
packets transmitted to or from its associated network. 
The tunnelling bridge includes tables indicated pairs of 
hosts or pairs of networks between which packets should 
be encrypted. When a packet is transmitted from a first 
host, the tunnelling bridge of that host's network inter- 
cepts the packet, and determines from its header infor- 
mation whether packets from that host that are directed 
to the specified destination host should be encrypted; or, 
alternatively, whether packets from the source host's net- 
work that are directed to the destination host's network 
should be encrypted. If so, the packet is encrypted, and 
transmitted to the destination network along with an en- 
capsulation header indicating source and destination in- 
formation: either source and destination host addresses, 
or the broadcast addresses of the source and destination 
networks (in the latter case, concealing by encryption the 
hosts' respective addresses). An identifier of the source 



network's tunnelling bridge may also be included in the 
encapsulation header. At the destination network, the as- 
sociated tunnelling bridge intercepts the packet, inspects 
the encapsulation header from an internal table deter- 
mines whether the packet was encrypted, and from ei- 
ther the source (host or network) address or the tunnel- 
ling bridge identifier determines whether and how the 
packet was encrypted. If the packet was encrypted, it is 
now decrypted using a key stored in the destination tun- 
nelling bridge's memory, and is sent on to the destination 
host. The tunnelling bridge identifier is used particularly 
in an embodiment where a given network has more than 
one tunnelling bridge, and hence multiple possible en- 
cryption/decryption schemes and keys. In an alternative 
embodiment, the automatic encryption and decryption 
may be carried out by the source and destination hosts 
themselves, without the use of additional tunnelling 
bridges, in which case the encapsulation header in- 
cludes the source and destination host addresses. 
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Description 

The present invention relates to the field of secure transmission- of data packets, and in particular to a new system 
(or automatically encrypting and decrypting data packets between sites on the Internet or other networks of computer 
networks. 

It is becoming increasingly useful for businesses to transmit sensitive information via networks such as the Internet 
from one site to another, and concomitantly more urgent that such information be secured from uninvited eyes as it 
traverses the internetwork. At present, unsecured data is replicated at many sites in the process of being transmitted to 
a destination site, and trade secret or other private information, unless secured, is thereby made available to the public. 

It is possible lor a user at the sending host to encrypt the data to be sent, and to inform the user who is to receive 
the data of the encryption mechanism used, along with the key necessary to decrypt. However, this requires communi- 
cation and coordinated effort on the parts of both the sending and receiving users, and often the users will not take the 
requisite trouble and the packets will go unencrypted. 

Even when these packets are encrypted, the very fact of their being transmitted from user A to user B may be 
sensitive, and a system is needed that will also make this information private. 

Figure 1 illustrates a network of computer networks, including networks N1 , N2 and N3 interconnected via a public 
network 10 (such as the Internet). When network N1 is designed in conventional fashion, it includes several to many 
computers (hosts), such as host A and additional hosts 20 and 30. Likewise, network N2 includes host B and additional 
hosts 40 and 50, while network N3 includes hosts 60-90. There may be many hosts on each network, and many more 
individual networks than shown here. 

When a user at host A wishes to send a file, email or the like to host B, the file is split into packets, each of which 
typically has a structure such as packet 400 shown in Figure 7, including data 410 and a header 420. For sending over 
the Internet, the header 420 will be an internet protocol (IP) header containing the address of the recipient (destination) 
host B. In conventional fashion, each data packet is routed via the internetwork 10 to the receiving network N2, and 
ultimately to the receiving host B. 

As indicated above, even if the user at host A encrypts the file or data packets before sending, and user B is equipped 
with the necessary key to decrypt them, the identities of the sending and receiving hosts are easily discernible from the 
Internet Protocol (IP) addresses in the headers of the packets. Current internetworks do not provide an architecture or 
method for keeping this information private. More basically, they do not even provide a system for automatic encryption 
and decryption of data packets sent from one host to another. 

The system of the invention includes a tunnelling bridge positioned at the interlace between a private network and 
a public network (or internetwork) for each of a number of such private networks. Each tunnelling bridge is a stand-alone 
computer with a processor and a memory, and in each tunnelling bridge's memory is a hosts table identifying which 
hosts should have their data packets (sent or received) encrypted. Alternatively, a networks table could be used, indi- 
cating whether data packets to and from particular networks should be encrypted; or other predetermined criteria may 
be stored that indicate whether particular data packets should be encrypted. 

The tunnelling bridge lor a given private network (or subnetwork of a private network) intercepts all packets sent 
outside the network, and automatically determines from the tables whether each such packet should be encrypted. If 
so, then the tunnelling bridge encrypts the packet using an encryption method and key appropriate lor the destination 
host, adds an encapsulation header with source and destination address information (either host address or IP broadcast 
address for the network) and sends the packet out onto the internetwork. 

At the destination host, another tunnelling bridge intercepts all incoming data packets, inspects the source and 
destination address information, and determines from its local hosts (or networks) table whether the packet should be 
decrypted, and it so, by what method and using what key. The packet is decrypted, if necessary, and sent on to the 
destination host. 

In this way, all messages that are predetermined to require encryption, e.g. all messages from a given host A to 
another host B, are automatically encrypted, without any separate action on the part of the user. In this way, no one on 
the public internetwork can determine the contents of the packets. K the encapsulation header utilizes the network IP 
source and destination addresses, with the source and destination host addresses encrypted, then the host identities 
are also concealed, and an intervening observer can discern only the networks' identities. 

The encapsulation header may include a field with an identifier of the source tunneling bridge. This is particularly 
useful if more than one tunnelling bridge is to be used for a given network (each tunnelling bridge having different 
encryption requirements and information), and in this case the receiving tunnelling bridge decrypts the data packets 
according to locally stored information indicating the encryption type and decryption key for all packets coming Irom the 
source tunnelling bridge. 

By way of example only, specific embodiments of the present invention will now be described, with reference to the 
accompanying drawings, in which 

Figure 1 is a diagram of a network ol computer networks in conjunction with which the system of the present invention 
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^Se 6 is a .low chart illustrating the method o. signatureless tunnelling ol the present invention. 

Figure 7 illustrates a conventional data structure for a data packet of the invention . 

. ,.„lng M*. - TO. TB2 -». TB3. ■««"*- ■^^^L^^««»<<*>** 

1 , features of, respectively, hosts A and R imD i emen ted in a separate, conventional computer having a 

Each of the tunnelling bridges TB1-TB3 "Vf'^^ZvSwe combination of random-access-memory 
processor and a memory, as shown in Figure 4. J^^^, CD-ROMs, etc. The program instruc- 

30 (BAM), read-only-memory ^^^J^^^S^mi are executed by their respects 
tions for each of the bridges TB1-TB3 are stored n ™" binatton of ste ps executed as necessary 

microprocessors. The method of the present JSSJSE and me receiving host B. 

by each of the processors of the sending host A, the tun ^S^SSnUScS ^but the particular encryption mechanism 
Encryption ol da.a is an important step ,n the overall ^ZoL such as the DiHie-Hellman method 
35 used is not crKical. It is preferable to use •^iSSSS^^S^^ '"">— ^ N ° Vembe ' 
(S ee W. DHfie and M. Hellman, 'New ° K ^^^^^^L i in some detail in applets copending 
1976). (The use of encryption in connection wrth IP , or Use Wltn lntern et Protocols at Sire F.re- 

patent applied ^ 

- r; b nre^P— ^ 

h cs, A The user at host A enters <*«^"^££^ ^0^0 data packets as in Figure 7, 
the host computer A carries out the standard P^f^^"j2 n „ ie8lonB ove r the Internet, this will be the IP 
each including both the data 410 and a ^^**™« """"Sc implements, it shoutd be under- 
header Though the current discussion will be directed in large pan to ir-sp* ■ * 

stS tha, anjnetwork protocol may be used in ^^^ZZZuZ^ for send^g the file, email. 

At box 200, the user at host A (see Figures 3 and 6) enters the ^orwera £ach 
or the like ,0 a recipient, and host A generates data ^^T^^^^u^^OM^ 
data packet initially has a structure like that of data P^^^!^ p addri. of host B. 
Md 420. The header 420 includes the ■ desl,na,on addr s, ,n this «*J*£^ Howevef „ box 220 , each 

The data packets are g^*^"^ M any of modes 2, 2A. 3 or 3A is used 

packet is intercepted by the tunnelling bridge TB 1 <see Figures « h * ^ ^ ^ 

fsee discussion below). When mode 1 (described betow) » used, s eps 220 utmd 1 2BD«e acc0 mplished by 

no, use tunnel.ing bridges; instead, the ^J^X^^SZ£ SUJ ! wherever TBt'or TB2 is 

respectively. 
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Stored in the memory of TB1 (or host A, for mode 1 ) is a look-up table (not separately shown) of the addresses of 
hosts, both on the local network N1 and on remote networks such as N2 and N3, and an indication for each network 
whether data packets from or to that host should be encrypted. For instance, in this case the hosts table of TB1 indicates 
that any messages sent from host A to host B should be encrypted. Thus, bridge TB 1 (or host A) looks up hosts A and 
B in its tables, and determines that the data packets to be transmitted must first be encrypted, as indicated at boxes 
230 and 240 of Figure 6. 

Alternatively, the table could stored the network identifiers (e.g. broadcast addresses) of networks N1 and N2, 
indicating that anything sent from network N1 to network N2 is to be encrypted. In this case, the table need not list each 
host in each network, which makes the table smaller and easier to maintain. 

If each host is listed, however, greater flexibility can be retained, since it may be that messages to or from particular 
hosts need or should not be encrypted. In an alternative embodiment, the look-up table lists the networks N1 and N2 
as networks to and from which packets should be "encrypted, and also includes a hosts section of the table indicating 
exceptions to the normal encryption rule for these networks. Thus, if networks N1 and N2 are listed in the look-up table, 
then packets travelling Irom N1 to N2 should normally be encrypted; however, if there is an "exceptions" subtabte indi- 
cating that no packets from host A are to be encrypted, then the normal rule is superseded. The exceptions can : of 
course, go both ways: where the normal rule is that the packets for a given network pair should/should not be encrypted, 
and the exception is that tor this given host (source or recipient) or host pair, the packet should not/should nonetheless 
be encrypted. In this embodiment, the small size and ease of maintenance of the network tables is by and large retained, 
while the flexibility of the hosts table is achieved. 

If the data to be transmitted from host A to host B (or network N1 to network N2) should not be encrypted, then the 
method proceeds directly to step 270, and the packet in question is transmitted unencrypted to the destination, via the 
Internet (or other intervening network). 

In this example, the packets are encrypted at box 250. This is carried out by the tunnelling bridge TB1 , according 
to whichever predetermined encryption scheme was selected, the primary requirement being that of ensuring that TB2 
is provided with the same encryption scheme so that it can decrypt the data packets. TB2 must also be provided in 
advance with the appropriate key or keys for decryption. 

The Encapsulation Header 

At box 260, an encapsulation header is appended to the encrypted data packet. This header can take one of several 
alternative forms, according to the requirements of the user. Several modes of packet modification can be accommodated 
using the same basic data structure (but with differences in the information that is appended in the encapsulation header), 
such as the following: 



Mode 


Appended information 


1 


Encryption key management information (itself unencrypted) 




New IP header including originally generated IP addresses of source and destination hosts (unencrypted) 


2 


Encryption key management inlormation (in encrypted form) 




Tunnelling bridge identifier for sender (unencrypted) 




New IP header including broadcast addresses of source and destination networks (unencrypted) 


2A 


(Same as mode 2, but without the tunnelling bridge identifier.) 


3 


Encryption key management information (encrypted) 




Optional: tunnelling bridge identifier for sender (unencrypted) 




New IP header including originally generated IP addresses of source and destination hosts (unencrypted) 


3A 


(Same as mode 3, but without the tunnelling bridge identifier.) 



Data structures for modes 1, 2 and 3 are depicted in Figures 8, 9 and 10. respectively, wherein like reference 
numerals indicate similar features, as described below. The data structure for mode 2A is illustrated in Figure 11. and 
mode 3 A may use the data structure of Figure 8. 

The data structure 402 for mode 1 is represented in Figure 8. The original data 410 and original header 420 are 
now encrypted, indicated as (410) and (420). Encryption key management information 440 is appended (in encrypted 
form) as part of the new encapsulation header 430, along with a new IP header 450, including the addresses of the 
source and destination hosts. The information 430 includes indicates which encryption scheme was used. 

Key management information can include a variety of data, depending upon the key management and encryption 
schemes used. For instance, it would be appropriate to use applicant's Simple Key- Management for Internet Protocols 
(SKIP), which is described in detail in the attached Appendix A. 
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,n Figures 7-11. the »» - -rence -SSS^S^S^X 
crypted. Thus, in Figure 8, the origin*. data field 410 ^^^ZZ^l not encrypted, 
^der 430. inCuding , he Key management -^^^^^^^^^^^^ 

in this embodiment, the tunnelling bndges TB and TB2 y, kets are to be encrypted 

inc ,ude al, the instructions, tables, etc. ^^^^ db ^ to Entity the source and destination 
and using which encryption scheme Mode 1 a low anv '™ e 9 ^ etficient and automate encryption 

(instead of that of the hosts themselves), and in a ddton "™JM™ , hen be used by an intercepting computer 

method and key. three-bvte field, giving 2*< or over 1 6 million unique tunnelhng 

An appropriate tunnelling bridge .denser might be a th ee byte ne a |dentrfier |p 

bridge iiers. An arbitrarily .arge number of in m ua. ,u n I JJ^ST^ ol 9 a user . sele cted arbitrary 

""SrS SSI "^observer along the circuit taken by a g*en data packetcan decern on.y fhe —g bndg. 

identrtier and the IP broadcast like -129.144.0.0' w*Kh represents 

The IP broadcast address tor the destination network wiliiypicany db » intermediate points on the route 

a pabular network „n this case. -Eng.Sun.COM-) b -^^ , S t S^jS to -Eng.S^n.COM-, and the 
of the packet, * can be discerned that a ^^^^^.Sn^but L is the extent of it; the source and 
identification number of the receiving tunnel.mg J™*^**^"; data pac ket are all hidden. 
destinaHon hosts, the key management .nforma 

Mode 2A uses the data structure shown ,n F gure 11 ItO but oo tunne«ino brWge kSemmer is used. Th« 

^^^^^^^^^ « — — - — ° M ° f 
.ntercep.ed by the tunnelling bridge TB4. which ^^^^^"J^Z the pub.ic network and is 

bridge is used lor the entire source network or for ^"^^3^^006 on.y a given tunnelling bridge 
bridge identifier » no, a necessary Md m the ^ u ^^^iS. S). the identity of the source tunnelling 
could have intercepted packets froma g-ven hos e g TB4 tor hos 1 Cj g nostsand/OI networks cross^or- 

bridge is unambiguous, and the destmatj » ™ —ng bridge, TBS then proceeds 

related with TB4. Having determined that tunnelling bridge 1 B4 was 

with the correct decryption p| imi naies the need to "name- or number tunnelling bridges, 

This approach has certain advantages, namely that A a tunne „i ng bridge identifier field provides 

and reduces the sizes of the data packets by « ^ andeach subnetwork 

flexibility. For instance, in Figure 12. subne ^'^ ks rf N1 ^"^' .^^Xvely) Thus, subnetworks Nil and N12 can 

without altering it tor the other. 
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A packet traveling from host F to host E in Figure 12 will include a source tunnelling bridge identifier (TB7) so that, 
when it reaches TB6 at network N9, it is identified correctly as having been encrypted by TB7 and not TB8. In this way, 
tunnelling bridge TB6 need maintain a table only the information pertaining to the tunnelling bridges, and does not need 
to maintain encryption/decryption specifics for the host or network level. (Note that TB6 still maintains information relating 
to whether to encrypt messages sent between host A and host B or network N1 and network N2, as the case may be, 
as discussed above.) 

The tunnelling bridge identifier may be used for a variety of other purposes relating to the source tunnelling bridge, 
such as statistics recording the number of packets received from that tunnelling bridge, their dates and times of trans- 
mission, sizes of packets, etc. 

An alternative to the use of hosts or networks tables in the memories of the source and destination tunnelling bridges 
(or source and destination hosts, as the case may be) would be any information identifying one or more predetermined 
criteria by which the source host or source tunnelling bridge determines whether to encrypt a given data packet Such 
criteria need not merely be source and destination information, but could include packet contents, time of transmission, 
subject header information, user id., presence of a key word (such as "encrypt') in the body of the packet, or other criteria. 

Mode 3 uses a data structure 406 as shown in Figure 10. which is identical to the data structure 402 except for the 
addition ot field 460 containing the tunnelling bridge identifier, which is the same as the tunnelling bridge identifier dis- 
cussed above relative it mode 2. 

In this embodiment, as in mode 1, field 450 includes the original host IP addresses for the source and destination 
hosts (not the addresses of the networks, as in mode 2), and thus an observer of a mode 3 packet will be able to 
determine both the original sender ol the data packet and the intended receiver. Either mode contains sufficient infor- 
mation to route packets through an internet to a recipient network's tunnelling bridge for decryption and ultimate delivery 
to the recipient host. 

Mode 3A may use the data structure shown in Figure 8, in conjunction with a network configuration such as those 
shown in Figures 3 or 12. The mechanisms and relative advantages are identical to those described above for mode 
2A, while the structure reveals the source and destination host addresses. 

Whichever encapsulation header is added at box 260 (see Figure 6), the packet is, at box 270, then transmitted to 
the destination network. At box 280, the destination network's tunnelling bridge (here, TB2 shown in Figure 3) intercepts 
the packet, which is accomplished by an instruction routine by which all packets are intercepted and inspected for en- 
capsulation header information indicating encryption. 

Thus, at box 290, the encapsulation header of the packet is read, and at box 300 it is determined whether the packet 
was encrypted. If a tunnelling bridge identifier forms a part of the encapsulated packet, then the method of encryption 
and decryption key are determined from the destination tunnelling bridge's (or destination host's, in the case ol mode 
1 ) local tables. 

If no encryption was carried out on the packet, then it is sent on without further action to the correct host, as indicated 
at box 340. Otherwise, its encryption method is determined (box 320), and the packet is decrypted accordingly (box 
330), and then sent on as in box 340. 
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APPENDIX A 

Simple Key-Management For Internet Protocols (SKIP) Abstract 

Then; are occasions where i: is advantageous to put authenticity and privacy features at the net- 
work layer. The yast majority of the privacy and authentication protocols in the literature deal 
with session oriented key- rcanageroent schemes. However, many of the commonly used network 
layer proLccois le.g IP and I?ng) are session-less datagram oriented protocols. We describe a key- 
management scheme that is particularly well suited for use in conjunction with a session-less dat- 
agram protocol like IP or IP.ig. We aiso describe how this protocclcuy be used In the context of 
internet multicasting protocols. Tnis key-management scheme is designed id be plugged into the t 
IP Sec uricy Protocol (EPSP) <rz JPng . 

1.0 Overview 

Any kind of scalable and robust key-rnanagemem scheme that needs to scale to the number of 
-odes possible in the Internet needs to be based on an underlying public-key certificate based 
infrastructure. This is the direction thai, e.g. the key-management scheme for secure Internet, 
e-mail. Privacy Enhanced Mail or PEM [1], is talcing. 

Tne certificates used by PEM are RS A public key certificates. Use of RS A public key certificates 
also enable the establishment of an authenticated session key [2,3]. ("By an RS A public key certif- 
icate, what is meant here is that the key being certified is an RSA public key.] 

One way to obtain authentic.ry and privacy at a datagram layer like IP is to use RSA public key 
certificates. (In the following description we use the terra EP, although IP is rrplacablc by IPng in 
this context). 

Tnere are two ways RSA ceitficates can be used to provide authenticity and privacy for a data- 
gram protocol. The first way is to use out-of-band establishment of an authenticated session key, 
using one of several session key establishment protocols. This session key can then be used 
to encrypt IP data traffic. Sui:h a_ scheme has the disadvantage of establishing and maintaining a 
pseudo session state underneath a session-less protocol The IP source would need to firs: com- 
municate with the IP destination in order to acquire this session key. 

Also, as and when the session key needs to be changed, the IP source and the IP destination need 
to communicate again in ordur to cake this happen. Each such communication involves the use of 
a computationally expensive public-key operation. 

Tne second way an RSA cerdficacc can be used is to do in-band signaling of the packet encryp- 
tion key, where the packet encryption key ;s encrypted in the recipient's public key. This is the 
way, e.g, PEM and other public-key based secure e-cnaii systems do message encryption. 
Although this avoids the ses::ion state establishment requirement, and aiso does not require the 
two parties to communicate in ordcT to set up and change packet encryption keys, this scheme has 
the disadvantage of having tu carry the packet encryption key encrypted in :he redpiem'spublic 
key in every packet. 
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Since an RSA encrypted key would miranaJiy need to be 64 bytes, and can be 12S bytes, this 
scheme incurs the overhead of £4- 128 bytes of keying information in every packet. (As nine 
progresses, the RSA block ::ize would need co be closer to 123 bytes simply for securiry reasons.) 
Also, as and when the packer encryption key changes, a public key operation would need to be 
p erf armed in order to recover the new packet encryption key. Thus both the protocol and compu- 
tational overhead of such a scheme is high. 

Use cf certified Diffce-Hcilinan (DU) [4] public-keys can avoid the pscudo session state establish- 
ment and the commumcanens requirement berween the rwo ends in order to acquire and change 
packet encrypting keys. Furthermore, this scheme does not incur the overhead of carrying 
£A- 128 bytes of keying information in every packet. 

This kind of key- management scheme is better suited to protocols like IP, because it doesn': even 
require the remote side to bi up in order to establish and change packet encrypdon keys. This 
scheme is described in mon: detail below. 

2.0 Simple Key- Management for Internet Protocols (SKIP) 

We stipulate that each IP bssed source and destination has a certified Diffie-Heliman public key. 
This public-key is distribute d in the form of a certificate. The certificate can be signed using either 
an RSA or DS A signature algorithm. Kow the certificates are managed is described in more detail 
later. 

Thus each IP source or desti nation I has a secret vaJuc i, and a public value g**i mod p. Similarly, 
IP node J has a secret value j and a public value g**j mod p. 

Each pair of IP source and destination I and J can acquire 2 shared secret g**ij mod p. Tney can 
acquire this shared secret without actually having to communicate, as long as the certificate of 
each IP node is known to all the other I? nodes. Since the public-key is obtained from a 
certificate, one narural way for all parties to discover the relevant public-keys is co distribute these 
certificates using a director' service. 

This computable shared secret is used as the basis for a key-encrypting-key to provide for IP 
packet based authentication and encrypdon. Thus we call g**ij mod p the long-term secret, and 
derive from it a key Kij. Kr is used as the key for a shared-key cryptosyscem(SKCS) like DES or 
RC2. 

Kij is derived from g**ij rn-xi p by taking the high order key-size bits of g**ij mod p. Since g**)j 
mod p is minimally going to be 512 bits and for greater security is going to be 102* bits or higher, 
we can always derive enough bits for use as Kij which is a key for a SKCS, SKCS key sizes aie 
cypically in che range of 40-256 bus. 

An important point here is ihat Kij is an implicit pair-wrise shared key. It does not need co be sent 
in every packet or negotiated out-of-band. Simply by examining the source of an IP packet* the 
destination IP node can compute this shared key Kij. Because this key is implicit, and is used as a 
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raast£T key, Us length car. br. made as long as desired, without any.addioonal protocol overhead. i„ 
order to make cryptanalysi:; of Kij arbia-arily difficult. 

W- us* Kii to encrypt a transient key. which we call Kp (for packet key). Kp is then used, to 
r„^uth C nnc^an I? ,«ck« or collection of packer This is done in order » Unat *c lacraal 
axnoln: of data fa. the long- «nn key. Since we would like to keep the long-term . toy in _a rcla_ 
rively long period of time. ::ay one or two years. we don't encrypt the actual IP datt <rafSc m key 
Kij. 

Instead we only encrypt transient keys in this long-term key. and use the transient keys to encrypt/ 
authenticate IP deiTSfic. Tnis limits the amount of data encrypted i» the long-term *ey » a rel- 
atively small amount even over a long period of time like, say, one year. 

Thus the first rirae an IP soiree I, which has a secret value i, needs to communicate with IP desa- 
Son 1 ~h"h has a secret value j. u computes the shared secret g«y mod P U cat, then , denve 
ftom this shared secret the iong-term key Xij. IP source I then generates a nntonkey Kp and 
^crypts this key using Kij. It encrypts the relevant porter, of the IP packet in key K P (wh ch cay 
SlnSe IP packed just the^yload of the IP packet depending on the next-protccol field m 
IPSP protected data potion). 

The value of the SAD field is used by SKI? to indicate the mode of processing and to identify the 
implicit interchange key. Tj-pical modes cf processing are encrypted, er.crvpted-authenncated. 

auihcnricaied, compression etc. 

The modes of operation are identified by the upper 6 bits of the SAID field. The meanings of these 
Sper 6 bits is specified in section 2.5 below on SAID derived processing modes. The low 22 bus 

of ihe SAID field arc zero. 

If the next protocol field is IP, (in other words IPSP is operaung in encrypted -encapsu toM 
the packet looks as follows. It sends the encrypted IP packet, the encrypted key Kp. encapsulated 
in a clear outer IF Header. 
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Cleir I? Header / 

I IP protocol • IPS? 



ver. I SAID | Beginning of I?SP header 

Xij alg J Kp «ls 12 byt«s Ravd| 



Kp encrypted in xij / (typically 8-16 bytea? 



Heasags Indicator fee IV) / (typically 8 bytes) 



Protested IPSP Payload 



In order to prepare this packet for emission on the outbound side of IP node. I, no commumcauon 
was necessary with IP node J. 

When IP node 3 receives this packet, it also computes ihe shared secret Kij and caches it for lalex 
use. (In order to do this, if it didn't already possess I's ceruncatc, u may have obtained this from 
the local directory service.^ Using Kij ii obtains Kp, and using Kp it obtains the originaJ IP packet, 
which it men delivers to tht. appropriate place which is either a local transport enriry or another 
outbound interface. 

The Message Indicator (MI) is a field that is needed id preserve the statelessness of the protocol. 
If a single key is used in ortier to encrypt. multiple packets, (which is highly desirable since chang- 
ing the key on a per packet basis constitutes too much overhead) then the packets need to be 
decryptabie regardless of lest or out-of-order packets. The message indicator field serves this pur- 
pose. 

The actual content of the MI field is dependent on the choice of SKCS used for Kp and iis operat- 
ing mode. If Kp refers to a Dicck cipher (e.g., DES) operating in Cipher-Block- Chaining (C3C) 
mode, then the MI for the first packet encrypted in key Kp is the Initialization Vector (IV). For 
subsequent packets, the MI is the last biocksize-bits of ciphertcxt of the last (in transmit order) 
packet. For DES or RC2 this would be last 64 bits of the last packet. For scream ciphers like RC4, 
the MI is simply the count of bytes that have already been encrypted in key Kp (and can be 64 bits 
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long also). 

, u -^f^^ark-^ncrvotionkcvKc, she receiving 

If *e scarce I? node (I in this cue) de«d« » = h "^«k-. .n^M ^ P ^ 

!P node I can diuovs Uu, =«« ^ l "^^^tfis /staed- key 
cached value Kij to decrypt u:e encrypted p~x« k«y^-^ 5 V\ receiving ends, ud 

oieadon. Thus, without requiring «"^^Sr can* be changed 
v*houi necessitating the use of a pubhekey openoon. she packet encrypting y 

by the mnsxrirtng side. 

xined in a pai^ise fasten using a symmetric etypiosynsm 
2 1 SKIP for Packet Authentication 

identifier for the message digest algorithm. 

This mode of operation is ideated by the SAID value which is further specified in Section 2., 
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/ Clear I? Header 


/ 

i 


IP protocol - IPS? 


1 v e r. | SAID 


I 


Beginning of XPSP header 


1 Ki j alg 1 Kp alg | !*D alglfrs 


'dl 


(1 byte far each algorit>jn 


/ Kp encrypted in xij 


1 

/ 

i 

t 


(typically 8-i€ bytes) 


/ Pro-erted IPSP Payload 


1 

/ 
/ 
1 
I 




/ Message Digest encrypted in 


t 

Kp/ 

« 


(typically e-l& bycca) 



2.2 Intruder in the Middle Artacks 

Ur.authendcated DifSc-Hclirnan is susceptible to an intruder in the middle anack. To overcome 
this, authenticated Difne- Beilman schemes have been proposed, that include a signature opcra- 
r t on with the panics private signature keys. 

SKIP is not susceptible to intruder in the middle types of attacks. This is because the Dirfie-Hell- 
man public parameters are long- term and cerbfied. intruder in the middle attacks on DifSe-Hell- 
.-nan assume that the parties cannot detrrmine who the public Diffie-Hcllman keys belong 
:o. Cerbfied Diffie- Helknan public keys eliminate this possibility, without requiring any 
exchange cf messages berw ;en the rwo partes or incurring the computational overhead of large 
exponent exponentiations (e.g.. RSA signatures). 

2.3 Storage of Cached Key ; 

Since the Kij values need tc be cached for efficier.cy. reasonable safeguards need to be taken to 
protect these keys. 

One possible way to do this is to provide a hardware device to compute, store and perform cpera- 
dons using these keys. This device can ensure that thcie are no interfaces to extract the key from 
the device. 
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2.4 Manual Keying 

As an interim measure, in lae absence of certification hierarchies, nodes may ^ish » employ 
manually exchanged keyin; infermadon. To handle such cases, the pair key Kij can be the key 
that is manually setup. 

Since manual re-keying is slow and awkward process, it sriU makes sense to use fee two level 
keying structuzevand encrypt the packets has the same benefit as before, namely u avoids over- 
exposing The pair key which is advantageous to maintain over relatively long periods of tee. 
This is particularly true for high-speed network links, where it is easy to encrypt large amounts of 
data over a shon period erf time. 

2.5 Processing Modes and SAID values 

The upper 6 bits of the S A:D acid are used 10 indicate the processing mode. The processing 
modes defined so far art, encryption, authentication, compression, and packet sequencing (for 
playback protection). Sine: none of Lhese modes is murually exclusive, mul&plc bus being on 
indicate the employment of all the relevant processing modes. 

SAID bits 

Siz 22 Bit 23 Sie 24 Bit 25 Sic 2S 

Itncrypted I *uth.ineieated ! Compiled I Sequenced ^ Asvd I Rs *j^ 
t--— - - 

Bit 22 = 1 if packet is encrypted, Bit 22 = 0 otherwise ^ 

Bit 23 = 1 if packet is authenticated, Bit 23 = 0 otherwise 

Bit 24= 1 if packet is compressed before encryprion, Bit 24 = 0 otherwise, 

Bit 25 * 1 if packets are sequenced. Bit 25 = 0 otherwise 

Bits 26 and 27 axe reserved for future use, and shall be 0 unci specified. 

For example, to indicate that a packet is encrypted and authenticated, Bits 22 and 23" shall be one. 
3.0 SKIP tor Multicast IP 

It is possible to use this kind of scheme in conjunction with datagram multicasting protocols lilts 
1? (or IPng) multicast [5]. This requires key-management awareness in the estabiishmcn: and 
joining process of multicast groups. 

In order to distribute multicast keying material, the notion of a group owner needs to exist. When 
secure multicasting to mu)rjcas: address M is required, a group membership creation primitive 
will need to establish the sxoup secret value Km and :hc membership iist of z44i*ssci that are 
allowed to aansrrit and receive encrypted multicast datagrams to and from group address M. 
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The group key Km is not usrd as a packet encryption key, but rather as the group Interchange Key 
OK). 

Nodes Ashing to :ransmit/r:ceive encrypted datagrams to multicast address M need to acquire 
the group IK Km. This is dene by sending an encrypted/authenticated request to join primitive to 
che group owner. If the requesting node's address is pan of the group's membership, then the 
group owner wiU send the I< Km, and associated lifetiinc information in an encrypted packet, 
using the pairwjse-secure protocol described in Section 2 above. 

Transmining nodes to group address M will randomly generate packet encryption keys Kp, and 
encrypt these keys using Kr..i. The packet strjcmre is similar to the s cue cure used for encrypted 
unicasc JPSP packets, excep : for the fact that the packet keys Kp are not encrypted in the pair-wise 
keys Kij. but instead are encrypted using the group IK Km. An example encrypted multicast 
packet is shown below. 



0 12 3 



1 

/ 


! ■ 

Cl*ir I"? Header / 
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1 


t? protocol » IPS? 


1 


Ve:.i SAID I 


Besinning of IPSP hea<ier 


1 


:<p aic 1 3 bytaa Rsvd ! 




i 

/ 

1 


i 

Kp encrypted ir. Kjn / 

t 


teypicaily 8-1S bytes) 


1 

/ 
1 


.".essays Indicator (e.g. »vj / 

i 


(typically a Siytea) 


1 

f 

t 


i 

Protected IPS? Payioad / 




1 

i 


/ 
I 





TneTC arc two distinct advantages of this scheme. First, every member of the multicast group can 
change packet encryption k:ys as often as it desires, without involving key-serup communications 
overhead involving every member of the group. 

Second, since all the packe: encryrpion keys ire different, there is no, problem in using strcam- 
ciphers with multicast This is because each source of encrypted crafoc uses a different key- scream 
and thus there is no key-s:n:am reuse problem. If ill members of the multicast group used the 
same packet encryption key (as t.g stipulated in the current draft of S02.1Q key- management). 
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then key-seeded suxan: cipiicn =culd not be used with multicast. 

underlying key raanageme -.1 facility can be delisted. 
4.0 Management of DH ce-.-ancaies 

Since the nodes public DH values are -o=» , . fe ^ £u . opean 
™lti-dcr Creadon structure *.« :s b«ng depwy* *or ^ ^ Authofil *rLCA) 

Authorities (PCAS) a: the s-xond der and organizanonal Cas below that. 

ln ^don to the identity o«fic*«. -Men are *i»t « pan of ^^f^^Tp 
te^o need additional aut,on«oon «««fic.«a, ic . order »7^^*j£*ESno. use 

nSTe authority to £d a pabular IP address » a DH pubuc v^ue. 

We car, soil use the X.509/PEM create fcm*. . d ^ ^ * 

Ac certificate can be the numeric suing representor, of a bst of P addresses. 

Since *e ncd* only have »H public 

-themselves unable to issue »ta^Ttai L", 0 3" n e . p£M, where every 

certificate path in a leal nce.e. unlike the certificate laoareny employed in, e.. rem, 
leaf node is potentially a iogue CA. 

RSA or DSA ccrdficaie iss icd by the PC A. 

fhnn , nn ^ fica[C win also contain Infomau or. about whether Ac CA to whom auihor- 
An authorization ^ciuncaie cu^ ^ _ r . w u irh has debatable authority 

able, inen the CA cannot delegate authority fcr that range of addresses. 

Tne range of IP addresses :re identified in the audiorixidon cerate in the fonn of a lis: of IP 
address prefix, length pairs 
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5.0 X.509 Encoding of SKI? DH certificates 

5.1 Encoding of DH public values 

The encoding of a DH Public value ir. ar. X.509 certificate will be in :hc form of an INTEGER. 
The algorithm indentifier uiU be as defined in PKCS #3 [7]. Thus 

DHPublicKey ::- IWTEGS.R 

and from PKCS #3, 
AigariefraZdencif ier 

SEQUENCE { 

algorithm OBJECT IDSHTITIER 

SSQUEMCS t 

pclma INTEGER, p 

ba«;e INTEGER, 5 

pri vatevaluetength INTEGER OPTIONAL 

) 

I 

with the OBJECT IDENTIFIER value being 

dh.K«yAgreemene OBJECT IDEHTIFISfc : :- 

(isoil) sierabeirrbody (2) US(6<0) 

Z3ad3:.(U3549) F*«<-1 3 1 5 

which is also taken from PKCS #3. 

DHPublicKey is what gets encapsulated as the BIT STRING in SubjcciPviblicKeylnfo of an 
X.509 cenificaie in the obvious manner. 

5.2 Encoding of the Distin fished Name (DN) 

The certificate is allowed o bind multiple P addresses to a single public value id accommodate 
cases where a single LP naic has multiple IP addresses. The SEQUENCE OF construct in a DN 
readily allows for this. What is needed is an OBJECT IDENTIFIER for an AccritoteTypc specify- 
ing an IP address. This is c.efined here as, 

ipAddr«33 ATTRIBUTE WITH ATTRIBUTE -SWT AX 

Frir.tableStrinq (SIZE (1 . . ub-ipAddr»3 3 ) ) 
::• ( Ipsec-oid li N««d Co register ehia XXX 

*r.« CN ir. ^hc c«rt,i£icate can contain multiple 

of these by iterating on the SEQUENCE OF construct of the Relative 
Distinguished Name Sequence. 
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:; cither the hexadecimal rrprescnuuoii or sandvd dot nouuon rrpiv 



5.3 Encoding of an Authorisation Certifiers 

An auction ecrxifica.e Is associated each CA r*lo* the PCA level. T>>e a^onxanon 
6.0 Conclusions 

We have tiescn^d a schem.:. Sample ffldiu rep larenaem candidate 

the scalability and -robustness of a pubU- key cerc,nca<e cascc 

«f iv,;< < -heme is thai establishing and changing packet encrypting keys 

pseudo-session state between the iwo sides » «qn«d. 

in ^y ways the .eyman^ent scheme her. ST£££ 
. fcy PEM 111. Both use the concept o^^£«g <» ~ « £ £ *£J se^, pip- 
data ^ » a SXCS. wchavc 

* -P-cd to the overhead of PEM when used „ 
conjunction with an asymmetric key- management system. 

W- have also described how this scheme may be used in cenjuncdoo with dnpn ^ i» 
JroSs Noting t single encrypted dtupu. to be oulocui to all the xecemng node, 
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Claims 

1. A method for transmitting and receiving packets of data via an internetwork from a first host computer on a first 
computer network to a second host computer on a second computer network, the first and second computer networks 
including, respectively, first and second bridge computers, each of said first and second host computers and first 
and second bridge computers including a processor and a memory for storing instructions for execution by the 
processor, each of said first and second bridge computers further including memory storing at least one predeter- 
mined encryption/decryption mechanism and information identifying a predetermined plurality of host computers as 
hosts requiring security for packets transmitted between them, the method being carried out by means of the instruc- 
tions stored in said respective memories and including the steps of: 

(1) generating, by the first host computer, a first data packet for transmission to the second host computer, a 
portion of the data packet including information representing an internetwork address of the first host computer 
and an internetwork address of the second host computer; 

(2) in the first bridge computer, intercepting the first data packet and determining whether the first and second 
host computers are among the predetermined plurality oi host computers for which security is required, and it 
not, proceeding to step 5, and it so, proceeding to step 3; 

(3) encrypting the first data packet in the first bridge computer; 

(4) in the first bridge computer, generating and appending to the first data packet an enapsulation header, 
including: 

(a) key management information identifying the predetermined encryption method, and 

(b) a new address header representing the source and destination for the data packet, 
thereby generating a modified data packet; 

(5) transmitting the data packet from the first bridge computer via the internetwork to the second computer 
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network: 

(6) intercepting the data packet at the second bridge computer; 

(7) in the second bridge computer, reading the encapsulation header, and determining therefrom whether the 
data packet was encrypted, and if not. proceeding to step 10, and if so, proceeding to step 8; 

(8) in the second bridge computer, determining which encryption mechanism was used to encrypt the first data 

packet; 

(9) decrypting the first data packet by the second bridge computer; 

(10) transmitting the first data packet from the second bridge computer to the second host computer; and 

(11) receiving the unencrypted data packet at the second host computer. 

2. The method of claim 1. wherein the new address header tor the modified data packet includes the internetwork 
broadcast addresses of the first and second computer networks. 

3. The method ol claim 2, wherein the new address header for the modified data packet includes an identifier of the 
second bridge computer. 

4. The method of claim 1 . wherein the new address header of the modified data packet includes the address of the 

second host computer 

5. The method of Cairn 4, wherein the new address header for the modified data packet includes an identifier of the 

second bridge computer. 

6 A system for automatically encrypting and decrypting data packets transmitted from a first host computer on a first 
comouter network to a second host computer on a second computer network, including: 

atrst bridge computer coupled to the first computer network for intercepting data pa ckets »«^t»m 
said fist computer network, .he first bridge computer including a first processor and a first memory stonng nstruc- 
ions o executing encryption of data packets according to a predetermined ™W™ d "™ X ™ m ^™™ 

a second brSige computer coupled to the second computer network for intercepting data P^kets transmrtted 
,o saic l^ond computer network, the second bridge computer including a second processor and a second memo^ 
storina instructions for executing decryption of the data packets; ^„, it t;„r, 

said first host computer including a third processor and a third memory including instructions for transmrtt.ng 
a first said data packet from said first host to said second host; 

a" stored in said first memory including a correlation of at least one of the first host computer and the first 
network with one of the second host computer and the second network, respectively, 

tsuu^ons stored in said first memory for intercepting said first data packet before W^™^ 
network, determining whether said correction is present in said table, and ,. so, then -»»»B«*^£ £ 
first data packet according to said predetermined encryption/decryption mechanism, and transmitting the first data 

^SScTSS SSISS memory tor intercepting satf first data packet upon arri^l a, said second 
ne two k determining whether said correction is present in said table, and if so, men £, 
first data packet according to said predetermined encryption/ decryption mechan.sm, and transmitting the f.rsl data 
packet to ihe second host computer. 

7. The method of claim 6, wherein the new address header for the modified data packet includes the internetwork 
broadcast addresses of the first and second computer networks. 

8. The method of claim 7. wherein the new address header for the modified data packet includes an identifier of the 
second bridge computer. 

9. The method of claim 6, wherein the new address header of the modified data packet includes the address of the 
second host computer 
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10. The method of claim 9, wherein the new address header for the modified data packet includes an identifier of the 
second bridge computer. 

11. A method for transmitting and receiving packets of data via an internetwork from a first host computer on a first 
computer network to a second host computer on a second computer network, the first and second computer net- 
works, each of said first and second host computers including a processor and a memory for storing instructions 
tor execution by the processor, each said memory storing at least one predetermined encryption/decryption mech- 
anism and a source/ destination table identifying a predetermined plurality of sources and destinations requiring 
security for packets transmitted between them, the method being carried out by means of the instrucdons stored in 
said respective memories and including the steps of: 

(1) generating, by the first host computer, a first data packet for transmission to the second host computer, a 
portion of the data packet including information representing an internetwork address of a source of the packet 
and an internetwork address of a destination ol the packet; 

(2) in the first host computer, determining whether the source and destination o1 the first data packet are among 
the predetermined plurality of sources and destinations identified in said source/destination table for which 
security is required, and if not, proceeding to step 5, and if so, proceeding to step 3; 

(3) encrypting the first data packet in the first host computer; 

(4) in the first host computer, generating and appending to the first data packet an enapsulation header, includ- 
ing: 

(a) key management information identifying the predetermined encryption method, and 

(b) a new address header identifying the source and destination for the data packet, 
thereby generating a modified data packet; 

30 

(5) transmitting the data packet from the first host computer via the internetwork to the second computer network; 

(6) in the second host computer, reading the encapsulation header, and determining therefrom whether the 
data packet was encrypted, and if not, ending the method, and if so, proceeding to step 7; 

36 

(7) in the second host computer, determining which encryption mechanism was used to encrypt the first data 
packet; and 

(8) decrypting the first data packet by the second host computer. 

40 

1 2. The method of claim 1 1 , wherein the new address header for the modified data packet includes internetwork broad- 
cast addresses of the first and second computer networks. 

13. The method ol claim 11 , wherein the source/destination table includes data identifying internetwork addresses ol 
46 the first and second host computers. 

14. A system for automatically encrypting and decrypting data packets transmitted from a first host computer on a first 
computer network and having a lirst processor and a first memory, via an internetwork to a second host computer 
on a second computer network and having a second processor and a second memory, the system including: 

so security data stored said first and memories indicating that data packets meeting at least one predetermined 

criterion are to be encrypted; 

a predetermined encryption/decryption mechanism stored in said first and second memories; 
a decryption key stored in said second memory; 

instructions stored in said first memory lor determining whether to encrypt data packets, by determining 
55 whether said predetermined criterion is met by said data packet; 

instructions stored in said first memory for executing encryption according to said predetermined encryp- 
tion/decryption mechanism of at least a first said data packet, when said criterion is met, and for appending an 
encapsulation header to said first data packet and transmitting said first data packet to said second host, said 
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«n£J5^£* said securily da ta. and i. so then defining wh.h encrypt^dec^ptK. mechan.sm 
was used for encryption, and decrypting said data packet by use of sad decryption key. 

1S " tT^^'^S- -region data stored in each o, said firs, and second -rnaies ^n =g at 
.eastoToSs^ 

^ te s e ys"m"r inc.uding instructions stored in sa* first memo* for determining Aether to ^encrypt d*to 
packed ^by inspecting for a matcS between source and Minricn addresses ot said data packets wrth sad corre- 

lation data. 
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